[TriPython] Places to look at performance tuning
David Handy
david at handysoftware.com
Tue Jun 6 22:31:10 EDT 2017
By the way, your I/O waiting could be on database sockets as well as on communication with the browser.
On Tuesday, June 6, 2017 10:28pm, "David Handy" <david at handysoftware.com> said:
Hi Ken -
Your previous email said your web server is running on CentOS and your database is MS SQL Server Express (running on a Windows server, presumably.)
What does the CPU usage look like on your web server and database server, respectively, during a test? (It would probably help to have a test where you do several consecutive requests, to make CPU usage more obvious.)
David H
On Tuesday, June 6, 2017 5:31pm, "Ken MacKenzie" <ken at mack-z.com> said:
> _______________________________________________
> TriZPUG mailing list
> TriZPUG at python.org
> https://mail.python.org/mailman/listinfo/trizpug
> http://tripython.org is the Triangle Python Users Group
> Wait brain fart, that actually goes back to the IO bound issue.
>
> Ok so let me think about this. If it is IO bound why does it still show
> near 20 seconds for TTFB?
>
> steps, rough outline
>
> take request
> based on route send request to function 1
> function 1 adds some gravy then redirects to a core function
> core function processes the query string in the request and...
> does the ORM filter and groub_by setup
> handles setting up the DictBundle
> for now also deals with date/time and decimal conversion on fields
> gets the data
> after all the data is back marshals it for the return (json by default
> but there is also a csv option)
> returns to function 1
> function 1 places returned marshaled data in resp.body and creates the
> resp.header
>
> When I was thinking IO bound I was thinking that it was the browser
> actually getting the response data over http.
>
> Perhaps my IO bound issues are in the creation of the objects or the
> marshaling the response
>
> to explain function 1 and core. core is a core transaction module,
> functions 1-3 are types of transactions expense, revenue, budget hence that
> division in the logic.
>
>
> On Tue, Jun 6, 2017 at 5:22 PM, Ken MacKenzie <ken at mack-z.com> wrote:
>
> >
> > (method 'poll' of 'select.poll objects) seems to be the place where I am
> > hitting the performance bottleneck.
> >
> > To me I could think of that as either the ORM or the previous indexing
> > suggestion or both.
> >
> >
> >
> Wait brain fart, that actually goes back to the IO bound issue.
> Ok so let me think about this.** If it is IO bound why does it still show
> near 20 seconds for TTFB?
> steps, rough outline
> take request
> based on route send request to function 1
> function 1 adds some gravy then redirects to a core function
> core function processes the query string in the request and...
> ** ** does the ORM filter and groub_by setup
> ** ** handles setting up the DictBundle
> ** ** for now also deals with date/time and decimal conversion on fields
> ** ** gets the data
> ** ** after all the data is back marshals it for the return (json by
> default but there is also a csv option)
> ** ** returns to function 1
> function 1 places returned marshaled data in resp.body and creates the
> resp.header
> When I was thinking IO bound I was thinking that it was the browser
> actually getting the response data over http.
> Perhaps my IO bound issues are in the creation of the objects or the
> marshaling the response
> to explain function **1 and core. **core is a core transaction module,
> functions 1-3 are types of transactions expense, revenue, budget hence
> that division in the logic.
> On Tue, Jun 6, 2017 at 5:22 PM, Ken MacKenzie <[1]ken at mack-z.com> wrote:
>
> (method 'poll' of 'select.poll objects) seems to be the place where I am
> hitting the performance bottleneck.
> To me I could think of that as either the ORM or the previous indexing
> suggestion or both.
>
> References
>
> Visible links
> 1. mailto:ken at mack-z.com
>
-------------- next part --------------
By the way, your I/O waiting could be on database sockets as well as on
communication with the browser.
On Tuesday, June 6, 2017 10:28pm, "David Handy" <david at handysoftware.com>
said:
Hi Ken -
Your previous email said your web server is running on CentOS and your
database is MS SQL Server Express (running on a Windows server,
presumably.)
What does the CPU usage look like on your web server and database server,
respectively, during a test? (It would probably help to have a test where
you do several consecutive requests, to make CPU usage more obvious.)
David H
On Tuesday, June 6, 2017 5:31pm, "Ken MacKenzie" <ken at mack-z.com> said:
> _______________________________________________
> TriZPUG mailing list
> TriZPUG at python.org
> https://mail.python.org/mailman/listinfo/trizpug
> http://tripython.org is the Triangle Python Users Group
> Wait brain fart, that actually goes back to the IO bound issue.
>
> Ok so let me think about this. If it is IO bound why does it still show
> near 20 seconds for TTFB?
>
> steps, rough outline
>
> take request
> based on route send request to function 1
> function 1 adds some gravy then redirects to a core function
> core function processes the query string in the request and...
> does the ORM filter and groub_by setup
> handles setting up the DictBundle
> for now also deals with date/time and decimal conversion on fields
> gets the data
> after all the data is back marshals it for the return (json by default
> but there is also a csv option)
> returns to function 1
> function 1 places returned marshaled data in resp.body and creates the
> resp.header
>
> When I was thinking IO bound I was thinking that it was the browser
> actually getting the response data over http.
>
> Perhaps my IO bound issues are in the creation of the objects or the
> marshaling the response
>
> to explain function 1 and core. core is a core transaction module,
> functions 1-3 are types of transactions expense, revenue, budget hence
that
> division in the logic.
>
>
> On Tue, Jun 6, 2017 at 5:22 PM, Ken MacKenzie <ken at mack-z.com> wrote:
>
> >
> > (method 'poll' of 'select.poll objects) seems to be the place where I
am
> > hitting the performance bottleneck.
> >
> > To me I could think of that as either the ORM or the previous indexing
> > suggestion or both.
> >
> >
> >
> Wait brain fart, that actually goes back to the IO bound issue.
> Ok so let me think about this.** If it is IO bound why does it still
show
> near 20 seconds for TTFB?
> steps, rough outline
> take request
> based on route send request to function 1
> function 1 adds some gravy then redirects to a core function
> core function processes the query string in the request and...
> ** ** does the ORM filter and groub_by setup
> ** ** handles setting up the DictBundle
> ** ** for now also deals with date/time and decimal conversion on fields
> ** ** gets the data
> ** ** after all the data is back marshals it for the return (json by
> default but there is also a csv option)
> ** ** returns to function 1
> function 1 places returned marshaled data in resp.body and creates the
> resp.header
> When I was thinking IO bound I was thinking that it was the browser
> actually getting the response data over http.
> Perhaps my IO bound issues are in the creation of the objects or the
> marshaling the response
> to explain function **1 and core. **core is a core transaction module,
> functions 1-3 are types of transactions expense, revenue, budget hence
> that division in the logic.
> On Tue, Jun 6, 2017 at 5:22 PM, Ken MacKenzie <[1]ken at mack-z.com> wrote:
>
> (method 'poll' of 'select.poll objects) seems to be the place where I am
> hitting the performance bottleneck.
> To me I could think of that as either the ORM or the previous indexing
> suggestion or both.
>
> References
>
> Visible links
> 1. mailto:ken at mack-z.com
>
More information about the TriZPUG
mailing list